问题所在
在浏览器中使用ES模块之前，开发人员还没有用于以模块化方式编
写JavaScript的本机机制。这就是为什么我们都熟悉“捆绑”的概念
的原因：使用将我们的源模块爬网，处理和连接成可以在浏览器中
运行的文件的工具。
随着时间的流逝，我们已经看到了诸如webpack，Rollup和Parcel之
类的工具，这些工具极大地改善了前端开发人员的开发体验。
但是，随着我们开始构建越来越雄心勃勃的应用程序，我们正在处理
的JavaScript数量也呈指数增长。大型项目包含数千个模块的情况并
不少见。我们开始遇到基于JavaScript的工具的性能瓶颈：启动开发服
务器通常会花费不合理的长时间等待（有时可能长达数分钟！），即使使
用HMR，文件编辑也可能需要花费几秒钟的时间才能反映出来。在浏览器中。
缓慢的反馈循环会极大地影响开发人员的生产力和幸福感。
Vite旨在通过利用生态系统中的新进步来解决这些问题：浏览器中本机ES模
块的可用性以及以本机语言编写的JavaScript工具的兴起。





服务器启动缓慢
冷启动开发服务器时，基于捆绑程序的构建设置必须急于爬网并构建整
个应用程序，然后才能提供服务。
通过将应用程序中的模块首先分为两类，Vite缩短了开发服务器
的启动时间：依赖项和源代码。
依赖关系大多是普通的JavaScript，在开发过程中不会经常更改。 
一些较大的依赖项（例如具有数百个模块的组件库）的处理成本也很高。
依赖项也可能以各种模块格式（例如ESM或CommonJS）提供。
使用esbuild查看捆绑前的依赖关系。 Esbuild是用Go语言编写的，
并且与基于JavaScript的捆绑器相比，捆绑前的依赖关系要快10到100倍。
源代码通常包含需要转换的非普通JavaScript（例如JSX，CSS或Vue / Svelte组件）
并且会经常进行编辑。 另外，并非所有源代码都需要同时
加载（例如，使用基于路由的代码拆分）。
Vite通过本机ESM提供源代码。 这实质上是让浏览器接管捆绑器的部分工
作：Vite只需要根据浏览器的要求按需转换和提供源代码即可。 
有条件动态导入后的代码只有在当前屏幕上实际使用时才被处理。




更新缓慢
在基于捆绑程序的构建设置中编辑文件时，由于显而易见的原因，
重建整个捆绑软件效率很低：更新速度会随着应用程序的大小线性降低。
某些捆绑程序开发服务器在内存中运行捆绑程序，因此仅在文件更改时
才需要使模块图的一部分无效，但仍需要重新构建整个捆绑程序并重新
加载网页。重建捆绑包可能会很昂贵，并且重新加载页面会破坏应用程
序的当前状态。这就是为什么某些捆绑软件支持热模块更换（HMR）的
原因：允许模块“热更换”自身而不影响页面的其余部分。这极大地改
善了DX-但是，实际上，我们发现，随着应用程序大小的增长，甚
至HMR更新速度也会大大降低。
在Vite中，HMR是在本机ESM上执行的。编辑文件时，Vite只需要
使已编辑模块与其最接近的HMR边界之间的链精确失效（大多数
情况下，仅是模块本身）即可使HMR持续快速更新，而不管
您的应用程序大小如何。
Vite还利用HTTP标头来加快整个页面的重新加载速度（再次，让浏
览器为我们做更多的工作）：通过304 Not Modified使源代码模块
请求成为有条件的，并且通过Cache-Control强烈地缓存依赖模块的
请求：max-年龄= 31536000，不可变，因此一旦缓存，
它们就不会再次击中服务器。
一旦您体验了Vite的速度，我们高度怀疑您是否愿意忍受捆绑开发。



为什么捆绑生产
尽管现在已经广泛支持本机ESM，但是由于嵌套导入导致的额外网络往返，
在生产中运输未捆绑的ESM仍然效率低下（即使使用HTTP / 2）。 为了在
生产中获得最佳的加载性能，最好还是将代码与树状摇动，延迟加载和通
用块拆分捆绑在一起（以获得更好的缓存）。
确保开发服务器与生产构建之间的最佳输出和行为一致性并不容易。 这就是
为什么Vite附带了一个预先配置的build命令，该命令可以立即进行许多性能优化。



为什么不与esbuild捆绑在一起？
尽管esbuild迅速发展，并且已经成为库的强大捆绑器，但是捆绑应用程序所
需的一些重要功能仍在开发中-尤其是代码拆分和CSS处理。 就目前而言，汇总
在这些方面更加成熟和灵活。 就是说，当将来在稳定这些功能时，我们不排除
使用esbuild进行生产构建的可能性。



#Vite与X有何不同？
您可以查看“比较”部分，以详细了解Vite与其他类似工具的不同之处。



